Rich media publishing

ABSTRACT

A media publishing system, comprising: a network interface to connect the media publishing system to a user; a plurality of web services to enable the user to build, publish, and access a media project using templates of media items grouped into categories; and a data storage to provide a file system to the plurality of web services, where the file system allows the user to access media items.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of priority of co-pending U.S.Provisional Patent Application Ser. No. 60/466,431, entitled “Rich MediaPublishing”, filed Apr. 28, 2003. Benefit of priority of the filing dateof Apr. 28, 2003 is hereby claimed, and the disclosure of theProvisional Patent Application is hereby incorporated by reference.

This application is related to co-pending U.S. patent application Ser.No. ______, entitled “Content Management for Rich Media PublishingSystem”, filed Mar. 30, 2004, Attorney Docket No. 450103-04598.2, andco-pending U.S. patent application Ser. No. ______, entitled “SupportApplications for Rich Media Publishing”, filed Mar. 30, 2004, AttorneyDocket No. 450103-04598.3. Disclosures of these U.S. Patent Applicationsare hereby incorporated by reference.

BACKGROUND

The rapid publication of media content is desirable for publishersintent on delivering media content faster to larger audiences. Thedigital representation of media content combined with computing andnetworking technologies now provide a powerful way to publish. Accordingto this new mode of publishing, networking technology permits thedelivery of digitized media content over a network to end usercomputers. Communication protocols define how the digitized mediacontent is exchanged over the network. A media player runs on the enduser computer (e.g., as software application) to allow the user to playor otherwise experience the media content.

Digital representations of media content come in different types. Thesetypes are generally defined according to a series of publishingvariables which can include, but are not limited to, the file format,bit rate, communication protocol(s), physical medium, compressionalgorithm, and/or digital rights management information associated withthe media content. The type of digitized media content used will dependupon a number of factors, such as, the computing and/or networkingtechnology used in the process of publishing and the nature of thecontent itself.

Digitized media content types can also be categorized according to thetype of encoding or compression technique that is used to reduce thephysical size of the media content, or according to the type of physicalmedium that supports the storage of the media content. Different kindsof physical medium are used in publishing media content, such asmagnetic or optical storage devices, memory devices, and wirelessmediums.

The emergence of a growing number of media players has created awidening gap between the richness of the various types of media contentand the diverse capabilities of the client devices to handle thecontent. As a result, the technology selection process for the end userhas become quite complicated. For example, the user often cannot becertain that a given media player will be able to play the type of mediacontent in which he or she is interested. Also, the user may be requiredto frequently download new media playing software in order to accessdesired content.

SUMMARY

This disclosure provides system and method of publishing a mediaproject. In one implementation, a media publishing system, includes: anetwork interface to connect the media publishing system to a user; aplurality of web services to enable the user to build, publish, andaccess a media project using templates of media items grouped intocategories; and a data storage to provide a file system to saidplurality of web services, where the file system allows the user toaccess media items.

In another implementation, a method of publishing a media projectincludes: selecting a category; selecting a template of media items fromthe category, said template of media items including a plurality ofmedia slots, each media slot capable of receiving media items in aparticular arrangement; and selecting and arranging the media items insaid each media slot.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A shows one implementation of a Rich Media Publishing environment.

FIG. 2A shows an example of the layout and features of a template.

FIG. 2B shows another example of the layout and features of a template.

FIG. 3 shows a flowchart of one implementation of building a project.

FIG. 4 shows a flowchart of one implementation of publishing a project.

FIG. 5 shows a flowchart of one implementation of accessing a publishedproject.

FIG. 6 shows a main build screen for selecting a template category froma list of media categories.

FIG. 7 shows a screen for selecting a project from a list of mediaprojects for the selected category.

FIGS. 8A and 8B show two preview screens for a selected template.

FIG. 9 shows a screen for editing the selected project selected in FIG.7.

FIG. 10A is an edit screen for editing a background template.

FIG. 10B is an edit screen for editing a music template.

FIG. 10C is an edit screen for editing a photo template.

FIG. 10D is an edit screen for editing an audio template.

FIG. 10E is an edit screen for editing a video template.

FIGS. 11 through 17 show screen shots for selecting a source for theimport file template.

FIGS. 18 through 23 show screen shots for selecting options inpublishing a project.

FIG. 24 shows a management screen for managing published projects.

FIG. 25 illustrates the Model-View-Controller (MVC) architecture inaccordance with one implementation.

FIG. 26 illustrates the interoperability of these software components inaccordance with one implementation.

FIG. 27 illustrates one implementation of component model interfaces forData Service Layer EJBs.

FIG. 28A shows the base build screen for an album template category.

FIGS. 28B through 28E show the base build screens for journal, e-card,music player, and game template categories, respectively.

FIG. 29A shows a browse templates pop-up screen.

FIG. 29B shows an upload files pop-up screen.

FIG. 29C shows an edit image pop-up screen.

FIG. 29D shows a template background pop-up screen.

FIG. 29E shows a template music pop-up screen.

FIG. 29F shows a journal add entry pop-up screen.

FIG. 29G shows an edit image in mask pop-up screen.

FIG. 30A shows a pipeline screen for entering display name of theproject.

FIGS. 30B and 30C show two pipeline screens for adjusting gallerysettings.

FIG. 30D shows a pipeline screen for entering names to share theproject.

FIG. 30E shows a pipeline screen for adding and/or editing the e-mailaddress entered in the share screen.

FIGS. 30F and 30G show pipeline screens for confirming and finalizingthe publication of the project.

FIG. 31A shows a pipeline screen for viewing a list of projects.

FIGS. 31B and 31C show project view screens of a published project for apremium member and a free trial member, respectively.

FIGS. 31D and 31E show personal gallery screens for a premium member anda free trial member, respectively.

FIG. 31F shows a pipeline screen for deleting a project.

FIG. 31G shows a pipeline screen for providing a HyperText MarkupLanguage (HTML) into the project website.

FIG. 31H shows a pipeline screen for changing gallery settings.

FIG. 31I shows a pipeline screen for entering names to share theproject.

FIG. 31J shows a pipeline screen for finalizing the updated settings forthe project.

FIGS. 32A and 32B show help screens for helping with preparation andaccess of the project according to one implementation.

DETAILED DESCRIPTION

This disclosure describes systems and methods that provide greaterefficiency and simplicity in publication of media contents. As usedherein, the term “media contents” refers to any information, includingaudio, video, images, sound, data, text, other contents, or combinationof these contents, which can be perceived by human senses.

Rich media publishing provides an environment for users to create andpublish media projects including various types of media. Users canselect various media items to be used in a project and then publish acompleted project to be viewed and experienced by others.

In one implementation, a user at a desktop or laptop computer connectsto a Rich Media Publishing (RMP) server system through the Internetusing a web browser software application. The RMP server system presentsa web site that, among other services, allows a user to build andpublish an RMP project. To build a project, the user selects an RMPtemplate. The template is a presentation framework and includes a numberof media slots. Each media slot defines a genre of media (e.g., image,audio, video) and a specific target format (e.g., a JPEG format imagethat is 320×480 pixels).

The user selects a media item for each media slot in the selectedtemplate from a repository according to the genre of the media slot. Therepository is part of the RMP server system and stores media items ofvarious genres in various formats. The user can also upload media itemsto be stored in the repository and select uploaded media items for mediaslots. The specific format of a selected media item does not need tomatch the target format of the corresponding media slot because the RMPserver system provides transcoding to convert a media item to the targetformat when presenting the project.

In addition, each template belongs to a category of templates. Templatesin the same category have the same number and genres of media slots.While each template may provide a different presentation, the mediaslots are the same, and so the same media items can be used fortemplates in the same category. As a result, the user can switch amongtemplates in the same category without changing the media itemselections. Further, the RMP server system enables producers to makechanges (e.g., fixes and/or updates) to the templates at one location,and allows the changes to take effect on all templates without anyaction taken by the user.

After the user has completed building the project, the user can publishthe project. The published project is available to the user and otherusers to access from the RMP server system. When a user accesses thepublished project, the RMP server system presents the template and themedia items assigned to the media slots of the user. The RMP serversystem provides the media items in the target formats defined by thetemplate and so provides appropriate transcoding. In this way, the usercan share media with other users in an enjoyable and creativeenvironment.

FIG. 1A shows one implementation of a Rich Media Publishing environment100. An RMP server system 105 includes components providing web services110 and data stores 115. The RMP server system 105 includes one or morenetwork servers (not shown) linked together in a local internal networkto implement these components. The web services 110 are a combination ofapplication programs to provide the services described below. In oneimplementation, the web services 110 are presented to a user as a website including a hierarchy of web pages with embedded controls. The datastores 115 include one or more data storage systems to provide databasestorage as well as file storage, such as in a hierarchical file system.The RMP server system 105 is connected to the public Internet 120 forcommunication with clients.

The web services 110 are provided by an RMP platform 112, a COREplatform (Create Once Render Everywhere) 114, and a content distributionplatform 116. The RMP platform 112 allows users to manage and publishmedia. The RMP platform 112 includes a Member Publishing service 160, aRepository service 162, Repository Filters services 164, andAdministrative services 166. The Member Publishing service 160 allowsusers to build RMP projects by manipulating data and media items, aswell as data structures forming the RMP templates. As discussed below,templates are built by producers (developers) using developmentapplications. Producers build templates according to guidelines set outin a Template Development Kit, distributed to producers. As discussedbelow, users interact with the RMP server system 105 through a clientsystem 125 to build a project based on a selected template and selectedmedia items. The Repository service 162 provides a repository that is avirtual file system that allows clients (users and producers) to accessmedia items available to projects. As discussed below, from the user'spoint of view, the media items are presented for selection andmanipulation by the user so as to appear to be stored in a hierarchicalfile system, while the actual organization of media items and data ishidden from the user. For example, while the user may be shown that allthe image media items are grouped together, in fact the image mediaitems are separated by format. The Repository Filters services 164provide a framework for performing operations on retrieved media itemsin the course of uploading and downloading media items. As discussedbelow, a filter performs one or more operations on a media item toconvert the media item (non-destructively) from its original format to aformat closer to or matching the target format specified by a template.Two examples of filters are an image manipulation system providingresizing of an image, and an audio transcoder for changing the format ofan audio media item (e.g., from MP3 to SWF). The Administrative services166 provide support for customer service (e.g., by allowing data andfile access and manipulation by a customer service client). In oneimplementation, the web services 110 also support subscriptions for userand payment facilities. In addition, the web services 110 can alsosupport different levels of subscriptions and so provide differentlevels of access to the services and resources of the RMP server system105.

The CORE platform 114 provides a multi-renderer multi-language enginethat allows multiple user interface (UI) representations to be derivedfrom a single source written in IDML (Interface Definition MarkupLanguage). As stated above, the CORE platform 114 enables Renderingservices 168, UI Management services 170, Publishing services 172, andContent Management services (CMS) 174. The Rendering services 168provide a rendering pipeline for transforming the IDML representation ofa UI into a specific XML rendering language (e.g., HTML, WML) and intohuman readable language. The UI Management services 170 provide supportfor a UI Management tool used by producers for editing IDML primitivesand collections. The Publishing services 172 provide a publishingpipeline that allows clients to select sources for both IDML and contentdata and target systems for deployment. The Content Management services174 provide support for managing content areas in the RMP server system105.

The CDP platform 116 provides support for identity and commercetransactions. The CDP platform 116 includes Identity services 176 andCommerce services 178. The Identity services 176 support registrationand login functionality. The Commerce services 178 provide access toproduct listings, pricing, and promotions, and support financialtransactions (e.g., credit card transactions).

A user system 125 is also connected to the Internet 120. The user system125 communicates with the RMP server system 105 through the Internet120. The user system 125 includes one or more end-user applications 130.The end-user applications 130 are for accessing the RMP server system105 and uploading and downloading data and media items to build,publish, and present RMP projects. In one implementation, the end-userapplications 130 include a web browser software application 126, amember publishing tool 128, a member publishing viewer 132, a web folder134, an upload control 136, and storage tools 138. The web browser 126is a HTTP/HTML client application. Applications from the RMP serversystem 105 can run in the web browser 126, such as a file accessapplication. The member publishing tool 128 runs embedded in the webbrowser (e.g., as a Flash application) and allows the user to build andpublish projects with the RMP server system 105. The member publishingviewer 132 runs embedded in the web browser 126 or as a separateapplication (e.g., as a Flash 5- or MX-based application) and allowsviewing of a project. The web folder 134 provides for manipulation ofmedia items and files stored on the RMP server system 105 using afolder-based file interface (e.g., the native Windows Explorerinterface). The web folder 134 interacts with the Repository service ofthe RMP server system 105. The upload control 136 is a control embeddedin the web browser (e.g., as an active X (win32 driven) control) andallows users to use “drag & drop” to upload files to the RMP serversystem 105. The upload control 136 also interacts with the Repositoryservice. The storage tools 138 also provide support for storing mediaitems on the RMP server system 105 (e.g., as native WIN32 applicationsproviding Sonic Foundry tools).

A producer system 135 is connected to the RMP server system 105. Inanother implementation, the producer system is included within the RMPserver system. In yet another implementation, the producer system isconnected to the Internet and communicates with the RMP server systemthrough the Internet. The producer system 135 includes one or moredevelopment applications 140. The development applications 140 are foraccessing the RMP server system 105 to build and support the webservices of the RMP server system 105, such as to build and publishtemplates for users to work with in building projects. In oneimplementation, the development applications 140 include a CORE UImanagement tool and a CMS tool. The CORE UI management tool supportsbuilding, editing, and publishing IDML user interfaces. The IDML UI'scan be designed to be renderer- and language-independent. The IDML UI'scan then be published in multiple rendering environments. The CMS toolsupports management of content written for a specific renderer. Thesetools support a separation of content and UI's.

A support system 145 is also connected to the RMP server system 105. Inanother implementation, the support system is included within the RMPserver system. In yet another implementation, the support system isconnected to the Internet and communicates with the RMP server systemthrough the Internet. The support system 145 includes one or moresupport applications 150. The support applications 150 are for accessingthe RMP server system 105 to support the web services of the RMP serversystem 105, such as for maintenance. In one implementation, the supportapplications 150 include a customer service application. A customerservice representative at the support system uses the customer serviceapplication to access and control a user's files, media items, andprojects.

The RMP environment allows a user to create and publish an RMP project.A user at a user system uses the end-user applications, such as a webbrowser and member publishing tool, to design the project. The RMPserver system builds the project using the Member Publishing service. Inaddition, the creation of a project is supported by the uploading andselection of media items in the repository of the RMP server system. Inone implementation, the RMP server system generates XML and/or HTML codefor a project, including links to data and media items stored in the RMPserver system. The generated code is used by client systems to presentthe project.

The Member Publishing service provides access to data structuresimplementing a collection of templates. A template has a layout and oneor more visual and/or audio features (e.g., background image, backgroundvideo, background music, animations, slide shows, sounds, controls,etc.). The layout and features are set by a producer that built thetemplate (e.g., using HTML code and corresponding media items). Thelayout and features of a template are generally not to be changed by anend-user. A template also has one or more media slots. A media slot isan open or undefined part of the template. A media item can be assignedto each media slot. In one implementation, a media slot has a datastructure (or part of a data structure) to store a reference to anassigned media item. In one implementation, the project is a datastructure that includes template data structure according to a selectedtemplate and includes a media slot data structure for each media slot inthe selected template. It is these media slot data structures thatindicate the assigned media items.

FIG. 2A shows an example of the layout and features of a template 200.In the template 200, a background image 205, a character body 210, andthe position of the character body 210 in the template 200 are setfeatures. The face 215 of the character is blank because the characterface 215 is a media slot. A user can select an image and assign theselected image to the media slot for the face 215. FIG. 2B shows anotherexample of a template 250. In the template 250, a rabbit character 255has a blank face 260 representing a media slot.

A media slot has a genre and a target format. The genre indicates thetype of media item that can be assigned to that media slot. For example,in one implementation, a media slot can have one of four genres: image,video, audio, or animation. Similarly, the Member Publishing servicerecognizes or determines a genre for any selected media item. The MemberPublishing service prevents a user from assigning a media item of thewrong genre to a media slot. However, within a genre, any format ofmedia item is acceptable. For example, for an image genre media slot, auser can select a JPG file, a GIF file, a bitmap file, or some otherstill image format file. The target format of a media slot indicates theformat in which the template causes the media item to be requested whenthe media item for the media slot is to be presented. When a project ispresented, the media item assigned to each media slot is retrieved andconverted to meet the target format of that media slot. The conversioncan be performed by the RMP server system, by the client system, or by acombination. These conversions are performed non-destructively so theoriginal media item is preserved in the repository. In addition, theseconversions are performed on the fly when the request to present aproject is made. Different levels of caching of converted media itemscan also be provided to improve performance at the cost of storage.

The templates are grouped into categories. Templates in the samecategory have the same media slots but can have completely different setfeatures. For example, referring again to FIG. 2, a second template inthe same category may have a different background scene and a differentcharacter body, but still has one media slot for an image. A thirdtemplate in the same category may have completely different featuresincluding multiple image features and background music, but still hasone media slot for an image. The media slots in templates in the samecategory also have a particular one-to-one correspondence. In anotherimplementation, there is a hierarchy of categories. In this case,templates at a lower level have the same media slots as the templateabove as well as additional media slots (similar to a class andsub-class relationship).

Because templates in the same category have the same number and genresof media slots, the template can be replaced with another template inthe same category without reselecting media items. Returning to theexample above shown in FIG. 2, if the user selects a new template in thesame category, the same image media item assigned to the image mediaslot in the original template will be assigned to the image media slotin the new template. In an implementation having a hierarchy ofcategories, a template can be switched to another template in the samespecific category or to a template in a parent category at a higherlevel. When switched to a higher-level template, media slots that arenot present in the higher-level template are dropped or renderedinactive.

From a data structure standpoint, in one implementation, the projectdata structure has a member for the features (the set features that donot change) of the selected template and for each media slot accordingto the selected template. Each media slot member indicates acorresponding media slot data structure. Each media slot data structurein turn indicates a media item. When the template is changed, the mediaslot data structures are not changed, but instead only data structuresreflecting the features of the new template are changed. In anotherimplementation, as discussed above, when the template is switched, thedata structure for each media slot, or a reference to that datastructure, is passed to the corresponding media slot in the new template(e.g., the data structure for the corresponding media slot in the newtemplate is set to store the reference to the same media item). Forexample, the first media slot of the original template indicates a mediaitem assigned to the first media slot by storing a reference to a datastructure indicating the media item. When a new template is selected toreplace the original template, the reference for the first media slot ispassed to the new template and the first media slot of the new templateis set to store that reference. As a result, the first media slot of thenew template then indicates the same media item as had been indicated inthe original template. Various other data structure implementations arealso possible.

A template can also have different versions for different platforms(e.g., computer web browser and phone web browser). Similar to templatesin the same category, platform templates (i.e., different versions of atemplate for respective platforms) have the same genre and number ofmedia slots and so are interchangeable, but the target format andcharacteristics of the media item requested can vary (e.g., requestingdifferent resolution images to accommodate different display devices).Similarly, the layout and features between platform templates can bedifferent. A project can list a single template and the initialconnection and requests from the user system establish the platform ofthe user system and so which platform template to use. Accordingly, inone implementation, the details of the platform template are kept at theRMP server system while the code for the project on the user system isthe same for each platform. In another implementation, some media slotsinclude variable characteristics that are dependent on thecharacteristics of the platform. In this case, the requests for mediaitems are customized by user system according to the characteristics ofthe user system.

In another implementation, a template also includes settable features. Asettable feature controls an aspect of the presentation of a projectsuch as background color or font characteristics. A settable featuredoes not have an assigned media item. As discussed above, media itemsare assigned to media slots. In one implementation, the settings forsettable features are reflected in HTML code for the project builtaccording to the template. The settable features in templates in thesame category also match to facilitate seamless transition betweentemplates. In another implementation, the settable features are uniqueto some or all templates and so do not carry over between templates inthe same category. As described below, a user selects settings for thesettable features while building the project. In another implementation,settable features are set automatically according to settings in a userprofile.

FIG. 3 shows a flowchart 300 of one implementation of building aproject. Before beginning, a user establishes a connection to the RMPserver system and accesses the Member Publishing service (e.g., bynavigating through a web site to a member publishing section). The useris presented with a collection of template categories and selects acategory, block 305. As described above, templates in the same categoryhave the same number and genre of media slots. In one implementation,each category represents a type of presentation with each template inthe category representing a particular style of that type ofpresentation. Examples of categories include, but are not limited to,albums, journals, scrapbooks, music players, e-cards, and games. The RMPserver system can present the categories for selection in various ways,such as in a list or a representation of folders similar to or withinthe repository.

After selecting a category, the user is presented with a collection oftemplates and selects a template, block 310. The RMP server system canpresent the templates in various ways, such as in a list of thumbnailimages, or a representation of folders similar to or within therepository. The RMP server system presents to the user one or morepreviews of how a project according to a template would appear. The usercan preview multiple templates before selecting one template to use forthe project. The user can also later change to another template.However, if the user changes to a template in a different category, someor all selections of media items may be lost.

After selecting a template, the user selects media items for the mediaslots in the selected template, block 315. The user selects a media itemfor each media slot in the template. The Member Publishing servicesupports selecting media items using various techniques, such as from alist, by entering a name, using drag and drop, or selecting from thefile system representation of the repository. A user can select adefault or recommended media item. A template can have a default mediaitem assigned to one or more media slots and the user can select thisdefault media item by not changing the assignment. A template can haveone or more recommended media items for a media slot and the user canselect one of the recommended media items, such as from a list. Defaultand recommended media items can also be established at a higher levelthan the template, such as for a category or for all templates. Inanother implementation, marketing information is used to recommend mediaitems to users. Default and recommended media items can also be linkedtogether into groups to form a set for the template. In addition, whenswitching between templates in the same category, when a default orrecommended item has been selected in the original template, the defaultor recommended item for the same media slot in the new template can alsobe used (although this new item may be a different media item). Defaultand recommended media items are stored in the repository.

A user can select a media item stored in the repository. The MemberPublishing service and the Repository service present to the user avirtual file system of media items to select from. For example, the useris presented with a hierarchy of folders of different types of mediaitems organized by the genre and content of the media items (e.g.,images of celebrities are grouped together). As discussed below, theRepository service hides the actual data storage of the media items(e.g., where media items are stored as physical files on one or moreservers organized by location which determined by a hash map algorithm)and instead presents the virtual file system. The repository includesmedia items provided by the RMP server system, media items uploaded andstored by the user (e.g., in a virtual set of folders under “My Files”),and media items uploaded by other users and made public.

A user can upload media items to the repository through the web browserapplication on the user's system. The web browser supports varioustechniques for uploading files, such as the web folder, the uploadcontrol, and the storage tools discussed above. The user can select amedia item stored on the user system and cause the upload using a nativefile service of the user system that interacts with the web browser orby providing a pathname to the web browser. The user can also drag anddrop a media item from within the GUI of the user system to the webbrowser. The drag and drop support allows a user to drag and drop amedia item directly into the web browser window and does not require aseparate window or interface as a visual target for the drag and dropoperation. In one implementation, the drag and drop support is providedthrough an embedded ActiveX control.

A user can also select a media item stored outside the repository. Theuser selects a media item from a source location, such as the usersystem or another network system, and the media item is uploaded to therepository. A reference to the selected item is stored in the repository(e.g., as a “virtual” media item).

While the user is selecting media items, the RMP server system presentsa preview of the project with the selected media items. Alternatively,the preview is presented upon demand. In this way, the user can evaluatethe choices made and change selections to improve the project. The usercan also change the template while selecting media items. If the newtemplate is in the same category as the former template, the selectedmedia items are preserved and the user does not need to select the mediaitems again. In an implementation supporting settable features, the useralso selects settings for the settable features at this time.

As the user selects a template and media items, the user can also editthe presentation of the project, block 320. As noted above, the RMPserver system presents a preview of the project. The user can adjustvarious aspects that the template has defined as being adjustable. Theuser can change the settings for settable features. The user can alsoadjust the presentation of media items that have an adjustablepresentation style. For example, an image media slot may have anadjustable size within the template. Another type of media slot has anadjustable level of zoom or rotation for an image or an adjustablecropping portion to present different sections of the image. Anothertype of media slot for an audio media item has an adjustable volume orbalance. The adjustments are recorded in the project and included in therequest to retrieve the media item when the project is presented. TheRMP server system provides the adjustments in presenting the media itemsas a conversion or filtering applied to the stored media item. The RMPserver system returns the result to the presenting application andcaches a copy of the result for future use. The original media item isnot changed. Alternatively, changes can be applied by the web browserapplication on the user system, or a combination of changes can beapplied at the RMP server system and at the user system.

As the user makes the selections and edits for the project, the RMPserver system builds and updates project code for the project. Theproject code is code to be used by the web browser of a user to presentthe project to the user. The project code includes instructionsaccording to the template and the selections and edits made by thepublishing user to present the project to a user according to thepublishing user's design. For some elements of the project, the projectcode includes instructions to the web browser on what to present, suchas text or a background color. For media items assigned to media slotsin the project, the project code includes requests to be sent to the RMPserver system. A request indicates the target format in which the RMPserver system is to provide the media item. A request can also indicateother changes or adjustments the RMP server system is to apply to themedia item, such as resizing. The project code can also includeinstructions for the web browser for modifications to apply to thereceived media items, such as rotation. In one implementation, some orall of the features to be presented as part of the project are includedin the project code as references to resources or code on the RMP serversystem. In this way, the RMP server system provides for syndication ofchanges, such as when templates are updated. Any changes made to thedata and template underlying a project will be provided transparently tothe s presented project without changing the project code. Thereferenced resource may change, but the reference itself can bemaintained.

When the user has completed editing, the RMP server system stores theproject code, block 325. The RMP server system provides storage for auser to preserve projects that have not yet been published. The user canreturn to the project for further editing at a later time. When the userhas finished editing a project, the user can publish the project. Theuser can later retract a published project or a copy of a publishedproject to the workspace area for modifications.

FIG. 4 shows a flowchart 400 of one implementation of publishing aproject. After a user has finished making selections and editing thepresentation of a project, the user can publish the project so thatother users can access and experience the project. The user selects orenters a publishing name for the project, block 405. The publishing nameis the name that will be used for other users to access the publishedproject. In one implementation, the publishing name is part of a URLprovided to users to access the published project.

The user selects a publication level for the project, block 410. Thepublication level indicates a range of users that will have access tothe project. At a public level, any user with access to the RMP serversystem will be able to access the project. In one implementation, theRMP server system provides galleries of projects including a publicgallery of projects that are available to users of the RMP serversystem. At a subscriber level, users that are subscribers to the RMPserver system services will be able to access the project. At anotherlevel of access, a defined group of users can access the project. In animplementation supporting galleries, the RMP server system providespersonal galleries for users where the user can define which other usersare allowed to enter the user's personal gallery and access projectswithin that gallery. The RMP server system can also provide other levelsof access, such as limited to the user only, limited to users with aninvitation from the publishing user, or limited to premium subscribers.

The user can also select a security level for the project, block 415.The security level restricts access within a publication level. Forexample, a user can assign a password to a project so that only usersthat enter the proper password can fully access the project. In oneimplementation, a user without the password can access a preview of theproject, but cannot fully access the project. The RMP server system cansupport various types of security mechanisms, such as digitalsignatures.

The user selects how to announce the published project, block 420. TheRMP server system provides an email notification system for newprojects. In one implementation, the email announcement includes a URLto access the project. The recipient can then activate the URL (e.g.,click on it) to proceed directly to the project. The user selects orprovides one or more email addresses to receive a notification of thenewly published project. In one implementation, the user provides emailaddresses from an email application program on the user system. Inanother implementation, the RMP server system maintains an emaildirectory of subscribers to the RMP server system to facilitatenotifications. In another implementation, the RMP server system providesa newsletter or news service to subscribers and the user can selectwhether to include a notice in the news service of the publication ornot, as well as what kind of notice.

After reviewing the selections made for publication, the user confirmsthe selections, block 425. Once the confirmation has been received, theRMP server system stores the project code in storage for publishedprojects and establishes access and security according to the user'sselections, block 430. The RMP server system also provides notificationsas indicated by the user's selections.

FIG. 5 shows a flowchart 500 of one implementation of accessing apublished project. Once the project has been published, users with theappropriate level of access and providing the appropriate security canaccess the project. A user accesses the RMP server system and selects aproject to experience, block 505. A user can browse through publiccollections or galleries of projects or personal galleries that are opento the user. A user can also request a particular project, such as byname. If a user has received a URL for a project, the user can accessthe project directly using the URL without navigating through the RMPserver system web site.

After selecting the project, the web browser at the user's user systemdownloads a copy of some or all of the project code for the project,block 510. The project code is the code built and stored by the RMPserver system when the publishing user built the project. The projectcode includes instructions for the web browser to present the projectincluding downloading media items. The web browser does not necessarilyimmediately download all the media items assigned to the project. Theweb browser can request and download the media items on demand as theproject is presented.

As media items are to be presented in the project according to theuser's actions and the project code, the web browser requests mediaitems from the RMP server system, block 515. The project code includes amedia item request for each media item assigned to the project. A mediaitem request indicates the media item, the target format, and anymodifications the RMP server system is to apply to the media itemaccording to the characteristics of the settings of the media slots. Asdiscussed above, media items can be presented as they are in storage, ina different format, or adjustments can be applied to the media item. Forexample, an image media slot in the project that has a target format ofJPEG sends a request to the RMP server system for the media item to bepresented as a JPEG media item. If the media item assigned to that mediaslot is in fact a different format, such as a GIF media item, the RMPserver system applies a filter to convert the GIF item to a JPEG itemand sends the JPEG item to the requesting user system. The request canalso include additional adjustments to the media item, such as resizing.

When the RMP server system receives a media request from the webbrowser, the RMP server system retrieves the indicated media item andapplies the appropriate modifications, block 520. The RMP server systemmaintains a cache of generated adjusted media items. The RMP serversystem first checks if there is already a copy of a media item matchingall aspects of the request in the cache. If so, the RMP server systemdoes not need to perform further modifications and returns a copy of thecached item. If not, the RMP server system retrieves the original mediaitem from the repository. The RMP server system checks if the media itemis in the format requested as the target format. If not, the RMP serversystem applies a filter to generate a new copy of the media item in thetarget format. If the request includes additional modifications to beapplied to the media item, such as resizing, the RMP server systemapplies the additional modifications to the filtered media item to matchthe request. The RMP server system returns the adjusted media item tothe user system and stores a copy in the cache.

In one implementation, the RMP server system also checks the cache forpartial matches to the request. In this case, if the cache includes anitem that matches part of the request without additional modifications,the RMP server system retrieves that item and applies the remainingmodifications to match the request. For example, where the request isfor a JPEG image at a particular resolution, the RMP server systemchecks the cache and determines that there is not a JPEG image at thatresolution for the indicated media item in the cache, but determinesthat there is a JPEG image at a different resolution for the indicatedmedia item in the cache. Instead of retrieving the original media item,which may be in a different format and could require a filter to be inJPEG format, the RMP server system applies an adjustment to change theresolution of the cached item to match the request, creating anothercopy in the cache. The RMP server system returns the new adjusted mediaitem matching the request. The RMP server system can use a prioritysystem to determine which partial matches to use. In anotherimplementation, the RMP server system determines whether it is better(e.g., faster) to undo one or more changes that have been applied to acached copy and then work forward rather than starting from the originalmedia item or from a cached copy that fewer changes applied.

In one implementation, the RMP server system provides the media item tothe web browser through a secure connection or using security measure tocontrol access. The RMP server system can use encoding for some or allmedia items sent to the user system (e.g., encoding items that are notfree). The RMP server system can also use access links that have alimited lifespan so that a request for the same media item will need touse a new access link after a period of time. As part of accessing theproject, the web browser receives and updates the access links tomaintain fresh links.

After the user system has received the media item matching the requestfrom the RMP server system, the web browser applies any additionalchanges indicated by the project code to the received media item, block525. As discussed above, the project code can indicate that somemodifications to a media item are to be applied by the web browserrather than at the RMP server system. For example, the project code mayindicate that, after the web browser receives the media item from theRMP server system, the web browser is to apply changes such as rotation,clipping, brightness adjustment, or volume adjustment. The web browserfollows a similar pattern to download and adjust any other media itemsas indicated by the project code.

After applying any local adjustments, the web browser presents theproject and media items to match the project code, block 530. Someaspects of the project do not require media items to be downloaded andare generated at the user system, such as fonts and colors. As the userinteracts with the project through the web browser, the project code mayindicate modifications are to be applied resulting in local adjustmentsmade by the web browser, new media item requests for the RMP serversystem, or combinations thereof.

In another implementation, layout information and features of theproject other than media items are also stored as requests in theproject code so that these items are also downloaded from the RMP serversystem. In this way, changes can be made at the RMP server system totemplates or media supporting templates (e.g., background images ormusic) and these changes will appear in all projects using the templatesas a result of the requests being sent back to the RMP server system.

In one implementation, the web browser and target formats used for mediaitems protect the media items from unwanted copying (unwanted from thepublishing user's or content owner's point of view). In oneimplementation, the rendering functionality of the web browser does notpresent any copy or save facility to a user. So the user can view theimages and video of a presentation, but the web browser does notdirectly support preserving the media items. A similar approach can beused with audio media items. In this way, it is difficult for users tomake unauthorized copies of media items presented in projects. Thisextra security may make it more desirable for content providers andusers to upload or provide access to content to be included in projects.

In one implementation, the RMP server system provides a code publishingservice. A user can download a copy of the project code for a projectand include that project code in any network accessible location. Theuser (or another user) can then access the stored project code andexperience the presentation without downloading the project code fromthe RMP server system. The RMP server system will still be involved inthe presentation because the media items assigned to the project arestored on the RMP server system, as well as some features of the project(e.g., template layout).

In one implementation, the RMP server system supports searching. A usercan search for media items, templates, or other data available throughthe RMP server system. The searching can apply to data provided by theRMP server system or to data uploaded to the RMP server system by theuser, another user, or a content provider.

In one implementation, the searching returns results that are contextsensitive. In one implementation, the search engine filters the resultsaccording to a user profile. Some media items available to the users arenot available for free. A user profile may specify a price limit forsearch results. Some media items are available to users according totheir subscription level. A user profile may indicate only to returnsearch results that are at a certain subscription level. Alternatively,the search engine may return only those results that are at the user'ssubscription level.

In another implementation, the search engine provides a preview feature.The search engine allows a user to select a search result and retrieve apreview of the indicated item, such as a thumbnail of a template orimage, or a short segment of a video or audio item. This preview may beprovided for a pay item before the user purchases the media item forinclusion in a project.

As discussed above, the repository is a storage system for the mediaitems available to and used in projects built and published through theRMP server system. The repository can be implemented as one or morestorage devices using one or more databases. In one implementation, eachtype of media item is stored in a respective storage device (e.g., JPEGimages on one storage device, MP3 files on a second storage device,streaming media on another storage device, and so on). The repositorymaintains information about the stored media items to present a virtualhierarchical file system to the user so that the user can easily access,move, add, and delete (etc.) media items according to a hierarchicalorganization. The user can create and delete folders in the repositoryand the RMP server system will present the media items according tothese folders even though the actual storage organization in therepository may be quite different. In addition, each user can have adifferent view of the data in the repository as the users builddifferent file structures, such as through the creation and modificationof virtual folders. Users can also customize the presentation features,such as types of folders, colors, etc.

The RMP server system also stores data in one or more databases and/orfiles to support the operation of the web site. This data is referred toherein as producer data. Producer data includes data to implement thetemplates, other than the media item data stored in the repository.Producers can access and modify media data in building and modifyingtemplates.

The RMP server system is supported by a client-side Content ManagementServices (CMS) tool. The CMS tool is for content management to allowproducers to access and manage the producer data and any media dataneeded for development. The CMS tool works with a multi-environmentpublishing pipeline to control access to and distribution of producerdata as it is being developed. For example, one publishing pipelinesupports three environments: a developing/production environment, astaging environment, and a live environment. Each environment maintainsa separate store of data. When a producer begins work on a template (forexample), the producer creates and edits the template and associateddata in the development environment. When the producer has completed thedevelopment work, the producer migrates the template and data to thestaging environment. A complete copy of the data is brought to the datastorage of the next environment. In the staging environment, thetemplate and data are tested and reviewed. When the template and dataare approved, they are migrated to the live environment. Again, acomplete copy of the data is brought to the data storage of the nextenvironment. In the live environment, users can access the template anddata for member publishing. Back-end constraints are provided to insurethat database conflicts are avoided from environment to environment.

In one implementation, producers are restricted to accessing data onlyin the development environment. Any changes made are submitted asupdates up through the pipeline. As updates are moved upward, theupdates are applied to the versions of data stored for each environment.In one implementation, the entire data set is not migrated upward, butonly the data or files that have been marked as modified.

In another implementation, a different number of environments aresupported, such as two, or four, or more. The number is customized tothe goals of the RMP server system, producers, and users.

In another implementation, the RMP server system provides simultaneoussupport for publishing of database items and physical files, using thesame user interface protocols. To a producer using CMS, database itemsare published in the same manner, e.g., with the same “PUBLISH/DELETE”flags for all items shown in the UI. The list of physical files to bepublished is constructed using a method that traverses both source anddestination file system trees, producing a list of differences that isdisplayed to the producer as files to be PUBLISHED or DELETED. This listis a selectable list of publishable physical files. In oneimplementation, the publishable physical files may be distributed inseveral different locations, such as in the repository of the RMP serversystem and/or in the local storage of the user system.

In another implementation, a producer can preview data through the CMS.A producer can preview a specific piece of producer content or aspecific physical file directly from the content management system(e.g., style sheets and JSPs, allowing a WYSIWYG preview of *MLcontent). In one implementation, the CMS tool provides a “Preview”button or supports a “double-click” of a particular item (e.g., forpreviewing items listed in the “Content” or “Tips and Tricks” tabs inthe illustrated figures below). The preview automatically launches theappropriate application or browser needed to see the content/file, andautomatically performs the necessary transformations on internal markuplanguage strings, using configuration settings and paths, allowing thatcontent to reference other content elements correctly. The producer canthen avoid having to access the content separately using the end-userrendering system.

Referring again to FIG. 1, it was disclosed that the user system 125includes one or more end-user applications 130, which are used foraccessing the RMP server system 105. The end-user applications 130include a web browser software application 126, a member publishing tool128, a member publishing viewer 132, a web folder 134, an upload control136, and storage tools 138. The member publishing tool 128 runs embeddedin the web browser (e.g., as a Flash MX-based application) and allowsthe user to build and publish projects with the RMP server system 105.The RMP server system 105 includes components providing web services 110and data stores 115.

In one implementation, the user interface for the member publishingincludes a Flash application, which enables the users to create uniqueflash-based presentations including their personal media. Theapplication enables users to upload their media into a number ofpredefined templates and then send or allow access to these completedprojects to friends and family. The user interface is developed in Flashto enable execution of business logic on the client side as well asdevelop a more robust user interface. In general, much of the logic ison the client side, and the interface with the server side is enabledvia the web tier, which includes Flash Remoting Gateway, ControllerEnterprise JavaBeans (EJB), and application processors. Thus, the webtier makes the application's business logic available on the Internet.

FIG. 6 through FIG. 24 illustrate screen shots of various userinterfaces for the member publishing tool in accordance with oneimplementation. For example, FIG. 6 shows a main build screen 600 forselecting a template category from a list of media categories. FIG. 7shows a screen 700 for selecting a project from a list of media projectsfor the selected category. In the illustrated implementation, theselected category is an elegant album. FIG. 8A and FIG. 8B show previewscreens 800, 810 for a selected template. FIG. 9 shows a screen 900 forediting the selected project selected in FIG. 7.

FIG. 10A through FIG. 10E show edit screens 1000, 1010, 1020, 1030,1040, respectively, for editing templates. FIG. 10A is an edit screen1000 for editing a background template. FIG. 10B is an edit screen 1000for editing a music template. FIG. 10C is an edit screen 1000 forediting a photo template. FIG. 10D is an edit screen 1000 for editing anaudio template. FIG. 10E is an edit screen 1000 for editing a videotemplate. FIG. 11 through FIG. 17 show screen shots 1100-1700 forselecting a source for the import file template. FIG. 18 through FIG. 23show screen shots 1800-2300 for selecting options in publishing aproject. FIG. 24 shows a management screen 2400 for managing publishedprojects. In one implementation, the files imported from many differentsources (e.g., from the user hard drive, from the RMP server repository,and/or from clips & effects). Furthermore, the files of different typescan be imported transparent to the user.

As mentioned above, in one implementation, the user interface for themember publishing tools is enabled via the web tier. The web tierdevelopment for member publishing system should be designed to achieveefficient processing of requests, and secure handling of personalizedinformation. Moreover, the web tier design should be extensible,scalable, and fault tolerant, and should be capable of supportingmultiple types of thick clients, including but not limited to Flash MXand Windows applications.

To accomplish the above-described web tier development goals, the memberpublishing system uses a hybrid Model-View-Controller (MVC)architecture. The following paragraphs describe what the MVCarchitecture attempts to achieve, the available variations of thearchitecture, and how and why this implementation uses a hybrid approachto Model 2 to meet the aforementioned goals.

The Model-View-Controller architecture is an architectural approach forinteractive applications. The architecture divides functionality amongobjects involved in maintaining and presenting data to minimize thedegree of coupling between the objects. The architecture mapstraditional application tasks—input, processing, and output—to thegraphical user interaction model. The architecture also maps into thedomain of multi-tier, web-based enterprise applications.

The MVC architecture divides applications into three layers—model, view,and controller—and decouples their respective responsibilities. Eachlayer handles specific tasks and has specific responsibilities to theother areas.

A model represents business data and business logic or operations thatgovern access and modification of this business data. Often the modelserves as a software approximation to real-world functionality. Themodel notifies views when it changes and provides the ability for theview to query the model about its state. The model also provides theability for the controller to access application functionalityencapsulated by the model.

A view renders the contents of a model. The view accesses data from themodel and specifies how that data should be presented. The view updatesdata presentation when the model changes. The view also forwards userinput to a controller.

A controller defines application behavior. The controller dispatchesuser requests and selects views for presentation. The controllerinterprets user inputs and maps them into actions to be performed by themodel. In a stand-alone GUI client, user inputs include button clicksand menu selections. In a web application, inputs include HTTP, GET, andPOST requests to the web tier. The controller selects the next view todisplay based on the user interactions and the outcome of the modeloperations. An application typically has one controller for each set ofrelated functionality. Some applications use a separate controller foreach client type, because view interaction and selection often varybetween client types.

FIG. 25 illustrates the Model-View-Controller (MVC) architecture inaccordance with one implementation. The illustrated implementationdepicts the relationships between the model, view, and controller layersof an MVC application.

Separating responsibilities among model, view, and controller objectsreduces code duplication and makes applications easier to maintain. Theseparation also makes handling data easier, whether adding new datasources or changing data presentation, because business logic is keptseparate from data. Further, it is easier to support new client types,because it is not necessary to change the business logic with theaddition of each new type of client.

Overall structure is the most important consideration in a web-tierdesign. Both the sample application and the various existing webapplication frameworks implement some form of “Model 2” architecture,where a servlet manages client communication and business logicexecution, and presentation resides mainly in Java Server Pages (JSP).

Model 1 and Model 2 refer to the absence or presence (respectively) of acontroller servlet that dispatches requests from the client tier andselects views. A Model 1 architecture includes a web browser directlyaccessing web-tier JSP. The JSP access web-tier JavaBeans that representthe application model, and the next view to display (e.g., JSP, servlet,HTML page, and so on) is determined either by hyperlinks selected in thesource document or by request parameters. A Model 1 application controlis decentralized, because the current page being displayed determinesthe next page to display. In addition, each JSP or servlet processes itsown inputs (parameters from GET or POST). In some Model 1 architectures,choosing the next page to display occurs in scriptlet code, but thisusage is considered poor form. Software maintenance on Model 1 isextremely expensive when constant updates are in place, since theprogrammer has to sift through piles of views to alter the site flow.

A Model 2 architecture introduces a controller servlet between thebrowser and the JSP pages or servlet content being delivered. Thecontroller centralizes the logic for dispatching requests to the nextview based on the request URL, input parameters, and application state.The controller also handles view selection, which decouples JSP pagesand servlets from one another. Model 2 applications are easier tomaintain and extend, because views do not refer to each other directly.The Model 2 controller servlet provides a single point of control forsecurity and logging, and often encapsulates incoming data into a formusable by the back-end MVC model. For these reasons, the Model 2architecture is recommended for most interactive applications.

An MVC application framework can greatly simplify implementing a Model 2application. Application frameworks such as Apache Struts include aconfigurable front controller servlet, and provide abstract classes thatcan be extended to handle request dispatches. Some frameworks includemacro languages or other tools that simplify application construction.

The Model 1 architecture can provide a more lightweight design forsmall, static applications. The Model 1 architecture is suitable forapplications that have very simple page flow, have little need forcentralized security control or logging, and change little over time.Model 1 applications can often be refactored to Model 2 when applicationrequirements change.

The Model 1 architecture is best when the page navigation is simple andfixed, and when a simple directory structure can represent the structureof the pages in the application. Such applications usually embed thepage flow information in the links between the pages. The presence of aforward in a JSP page implies that logic embedded in the page is makinga decision about the next page to display.

In a situation where there is a need for centralized security controland logging, the information being returned is a value objectencapsulating model data rather than the presentation of a view, and theclient is capable of performing its own logic, Model 2 provides a betterbasis from which to work.

The role of the Model 2 controller servlet will be partially fulfilledby the Flash MX remoting gateway, with the remaining functionalitysubsumed by a stateful EJB. The return from this EJB will be a valueobject rather than a view. The presentation of the view based upon thevalue object will be handled by the thick client. Additionally, some ofthe manipulation of model data may be done on the client before beingcommunicated back to the Controller for processing. Further, thedecoupling of the Controller into a servlet component and an EJBcomponent make it possible for future client communication protocols tobe easily handled.

As discussed above, in one implementation, the web tier includes a FlashMX remoting gateway, controller EJBs, and application processors. Thesesoftware components work together to accomplish personalized datamanagement per user and thick-client interaction for applicationproduction.

FIG. 26 illustrates the interoperability of these software components inaccordance with one implementation. In the illustrated implementation ofFIG. 26, the initial HTTP request is made of the Flash MX remotinggateway 2602. The request is passed along to the stateful EJB 2604 foruser tracking and delegation. The delegated request 2606, 2608, 2610, or2612 is processed by an application processor component 2620. Aconsolidated value object is then returned to the user 2600 with theoperation's results.

A servlet pipeline is not used in this architecture because the bulk ofthe work to be done is not handled by servlets. The majority of pre- andpost-processing requests can be handled by the thick-client. Although,in this case, a pipelining approach is a good general-case architecturalchoice, the approach may act as a detriment to performance whenidentifiable uses are minimal.

The Flash MX remoting gateway is a 3^(rd)-party servlet that provides ameans for Flash MX movies to communicate with server-side objects withminimal programming. Previous versions of Flash could make HTTP requestsfor data retrieval, including XML. The data returned would then need tobe converted into a format that could be understood by the FlashActionScript by the ActionScript programmer. This was especially truewith XML, as the support provided was limited and rather problematic.

With Flash MX, the capabilities have been expanded to now fully supportXML data at a native data type. Also, it understands a proprietaryformat that allows serializeable Java s objects to be automaticallytreated as ActionScript objects for direct use by the Flash programmer.The remoting gateway is the piece that handles communication between theclient movie and the server side to accept incoming HTTP requests and topass back results that are immediately available as native objects.

In one implementation, the gateway allows access to servlets, Javabeans, serializeable Java objects, and EJBs. To access these entities,the client must specify the gateway URL, a connection endpoint for theservice to be accessed, the method to be called on the service, and theparameters that will be supplied to the method call. The servletendpoint is given as a context root for the servlet, the serializeableJava objects' endpoint is given as a fully-qualified classpath, and theEJB endpoint is its JNDI entry. It is for security reasons that it ispreferable to use EJBs as the underlying controller for thisapplication, because no additional information about the code structureor deployment environment is made available by examining an in-the-clearHTTP request.

In instances when sending method calls and parameters in the clear isnot desirable, the requests may be made transparently over HTTPS. It isplanned that login/logout requests will be handled over this protocol.While all communications could be done in this manner, it is projectedthat the performance hit for all users would outweigh the minuteincremental security risk that someone could reverse-engineer the FlashMX protocol and attempt to inject malicious requests into the stream.

The Application delegator is a stateful EJB that acts as the other halfof the Controller. It provides the request flow with a centralizedlocation for common data handling, and manages the logic in charge ofdelegating actual request handling.

FIG. 27 illustrates one implementation 2700 of component modelinterfaces for Data Service Layer EJBs. This implementation indicatesthat an application processor, regardless of whether the request is madeby an end-user, creator, or in-house producer, can represent each actionthat may be requested by a client. One processor may handle one or moreactions. Each action affects state by committing such changes to abacking repository, though the action implementation itself is notstateful.

These processors may be implemented as Java beans, plain Java objects,or stateless EJBs. The main responsibility for each such processor is tohandle appropriate call parameters and perform their task as efficientlyas possible. Because the backing repository manipulation is a keycomponent of the performance, object creation and exception handlingneeds to be kept thin.

Referring again to FIG. 3, once the user enters the Member Publishingservice, the user is presented with a collection of template categories.As described above, examples of categories include, but are not limitedto, albums, journals, scrapbooks, music players, e-cards, and games.FIG. 28A through FIG. 28E show screen shots of base build screens inaccordance with one implementation of building a project. Each screenshot of the illustrated implementation shows an example of a template.For example, FIG. 28A shows the base build screen 2800 for an albumcategory template. FIG. 28B through FIG. 28E show the base build screensfor journal 2830, e-card 2860, music player 2870, and game 2880 categorytemplates, respectively.

Referring again to FIG. 28A, as an example, the base build screen 2800for the album category template includes a change template button 2802,a change background button 2804, a change music button 2806, a medialibrary screen 2808, a help button 2810, an album title area 2812, amedia item stage 2814, an edit image button 2816, a music player object2818, a launch player button 2820, a trash area 2822, a preview button2824, and a publish button 2826.

The change template button 2802 enables the user to change the template.The change background button 2804 enables the user to change thebackground of the template. The change music button 2806 enables theuser to change the template music. The media library screen 2808displays media-related items, such as recent downloads, clips & effects,and a list of media files. The media files include image, video, music,and other related multimedia files. Moreover, the user can drag and dropitems from the media library screen 2808 onto the media item stage 2814.The user can reorder and add titles and captions to the items on themedia item stage 2814. The user can enter a title for the project on thealbum title area 2812. The edit image button 2816 can be used to edit animage. The music player object 2818 enables playing of the music files.The launch player button 2820 launches an external multimedia player.The preview button 2824 enables the user to preview the project. Thepublish button 2826 prepares the project for publishing by collectinginformation related to publishing.

FIG. 28B shows the similar base build screen 2830 for the journalcategory template, which includes similar items including a changetemplate button 2832, a change background button 2834, a change musicbutton 2836, a media library screen 2838, a help button 2840, a journaltitle area 2842, a media item stage 2844, an edit journal entry button2846, a trash area 2848, a preview button 2850, and a publish button2852. The edit journal entry button 2846is used to navigate to journaladd/edit entry screen.

FIG. 29A through FIG. 29G show screen shots of pop-up screens inaccordance with one implementation of building a project. FIG. 29A showsa browse templates pop-up screen 2900; FIG. 29B shows an upload filespop-up screen 2910; FIG. 29C shows an edit image pop-up screen 2920;FIG. 29D shows a template background pop-up screen 2930; FIG. 29E showsa template music pop-up screen 2940; FIG. 29F shows a journal add entrypop-up screen 2950; FIG. 29G shows an edit image in mask pop-up screen2960. The pop-up screens may appear in response to actions taken in thebase build screens 2800, 2830, 2860, 2870, 2880, or in response toactions taken in other pop-up screens 2900, 2910, 2920, 2930, 2940,2950, 2960.

The browse templates pop-up screen 2900 allows the user to browsethrough the template category and to select a template. The upload filespop-up screen 2910 allows the user to drag and drop files on the uploadfiles area for uploading media files. The edit image pop-up screen 2920allows the user to edit the selected image. The template backgroundpop-up screen 2930 allows the user to select a template background. Thetemplate music pop-up screen 2940 allows the user to select a templatebackground music. The journal add entry pop-up screen 2950 allows theuser to enter journal entry. The edit image in mask pop-up screen 2960allows the user to edit the image in a mask.

Referring again to FIG. 4, after the user has finished making selectionsand editing the presentation of a project, the user can publish theproject so that the user and/or other users can experience the project.FIG. 30A through FIG. 30G show screen shots of a user publish pipelinein accordance with one implementation of publishing a project. The userpublish pipeline includes a pipeline for publishing the project builtaccording to the above-described process in connection with FIGS. 28 andFIGS. 29.

FIG. 30A shows a pipeline screen 3000 for entering display name of theproject. The display name of the project also includes the UniformResource Locators (URL) of the project file. FIG. 30B and FIG. 30C showtwo pipeline screens 3010, 3020 for adjusting gallery settings, whichinclude selections for the gallery area (i.e., the personal or thepublic galleries), whether to show or hide the gallery, and thepassword. FIG. 30D shows a pipeline screen 3030 for entering names toshare the project. In one example, the project can be shared by sendingout an e-mail invite to the e-mail address listed in the share screen.FIG. 30E shows a pipeline screen 3040 for adding and/or editing thee-mail address entered in the share screen. FIG. 30F and FIG. 30G showpipeline screens 3050, 3060 for confirming and finalizing thepublication of the project.

Referring again to FIG. 5, once the project has been published, userswith the appropriate level of access and capable of providing theappropriate security can access the project. FIG. 31A through FIG. 31Jshow screen shots of an access pipeline in accordance with oneimplementation of accessing a project. The access pipeline includes apipeline for accessing the project published according to theabove-described process in connection with FIGS. 30.

FIG. 31A shows a pipeline screen 3100 for viewing a list of projects.According to the illustrated implementation, the published projects canbe viewed, shared, edited, and/or deleted, while the unpublishedprojects can be edited or deleted. The individual project can be vieweddirectly by entering the URL of the project. The pipeline screen 3100also includes a button 3102 for viewing a personal gallery. FIG. 31B andFIG. 31C show project view screens 3110, 3120 for a published project.FIG. 31B is a project view screen for a premium member. FIG. 31C is aproject view screen for a free trial member, which includes a clickablearea to allow the free trial member to join the premium pay membership.FIG. 31D and FIG. 31E show personal gallery screens 3130, 3140 for apremium member and a free trial member, respectively. FIG. 31F shows apipeline screen 3150 for deleting a project. FIG. 31G shows a pipelinescreen 3160 for providing a HyperText Markup Language (HTML) into theproject website. FIG. 31H shows a pipeline screen 3170 for changinggallery settings. FIG. 31I shows a pipeline screen 3180 for enteringnames to share the project. In one example, the project can be shared bysending out an e-mail invite to the e-mail address listed in the sharescreen. FIG. 31J shows a pipeline screen 3190 for finalizing the updatedsettings for the project.

FIG. 32A and FIG. 32B shows help screens for helping with preparationand access of the project according to one implementation.

The various implementations of the invention are realized in electronichardware, computer software, or combinations of these technologies. Mostimplementations include one or more computer programs executed by aprogrammable computer. For example, referring to FIG. 1, in oneimplementation, the server system includes one or more computersexecuting software implementing the RMP environment. In general, eachcomputer includes one or more processors, one or more data-storagecomponents (e.g., volatile or non-volatile memory modules and persistentoptical and magnetic storage devices, such as hard and floppy diskdrives, CD-ROM drives, and magnetic tape drives), one or more inputdevices (e.g., mice and keyboards), and one or more output devices(e.g., display consoles and printers).

The computer programs include executable code that is usually stored ina persistent storage medium and then copied into memory at run-time. Theprocessor executes the code by retrieving program instructions frommemory in a prescribed order. When executing the program code, thecomputer receives data from the input and/or storage devices, performsoperations on the data, and then delivers the resulting data to theoutput and/or storage devices.

Various illustrative implementations of the present invention have beendescribed. However, one of ordinary skill in the art will see thatadditional implementations are also possible and within the scope of thepresent invention. For example, while the above description describescomputers connecting to servers through the Internet, additionalvariations and combinations are possible. For example, in otherimplementations, different types of network-enabled devices can be used,such as a network-enabled television or phone. Accordingly, the presentinvention is not limited to only those implementations described above.

1. A media publishing system, comprising: a network interface to connectthe media publishing system to a user; a plurality of web services toenable the user to build, publish, and access a media project usingtemplates of media items grouped into categories; and a data storage toprovide a file system to said plurality of web services, where the filesystem allows the user to access media items.
 2. The system of claim 1,further comprising: a plurality of network servers linked together in alocal network to provide an application programming environment for saidplurality of web services.
 3. The system of claim 2, wherein theapplication programming environment includes an RMP platform.
 4. Thesystem of claim 3, wherein the RMP platform includes a member publishingservice, a repository, a repository filters, and an administrativeservice.
 5. The system of claim 2, wherein the application programmingenvironment includes a create-once-render-everywhere (CORE) platform. 6.The system of claim 5, wherein the CORE platform includes a renderingservice, a user interface management service, a publishing service, anda content management service.
 7. The system of claim 2, wherein theapplication programming environment includes a content distributionplatform.
 8. The system of claim 7, wherein the content distributionplatform includes an identity service and a commerce service.
 9. Thesystem of claim 2, further comprising: a producer system including atleast one development application to build and support said plurality ofweb services, said producer system running on the applicationprogramming environment.
 10. The system of claim 1, further comprising:a client system to enable the user to access said plurality of webservices, said client system including at least one user interfaceapplication.
 11. The system of claim 10, wherein said at least one userinterface application includes a web browser.
 12. The system of claim11, wherein said client system further includes: a local storage tostore some of the media items to be used to build the media project. 13.The system of claim 12, further comprising: a web folder configured as afolder on the web browser.
 14. The system of claim 13, furthercomprising: an upload control tool to enable uploading of the mediaitems stored in said local storage to said data storage by dragging anddropping the media items directly into the web folder.
 15. The system ofclaim 1, wherein said network interface connects to a wide-area network.16. The system of claim 1, further comprising: a support systemincluding at least one support application to support at least one ofsaid plurality of web services.
 17. The system of claim 16, wherein saidat least one support application includes a maintenance application anda customer service application.
 18. The system of claim 1, wherein themedia items include background image, background video, backgroundmusic, animations, slide shows, sounds, and controls.
 19. The system ofclaim 1, wherein said plurality of web services includes a markuplanguage code for the media project, said code including links to mediaitems stored in said data storage.
 20. The system of claim 1, whereinthe template of media items includes settable features, which controlsan aspect of presenting the media project.
 21. The system of claim 20,wherein the aspect includes background color or font characteristics.22. The system of claim 20, wherein the settable features for templatesin a same category are configured to be same.
 23. A client system foraccessing and utilizing a media publishing system, comprising: a networkinterface to connect a user to the media publishing system; and at leastone user interface application to enable the user to build, publish, andaccess a media project using templates of media items grouped intocategories.
 24. The system of claim 23, wherein said at least one userinterface application includes a web browser.
 25. The system of claim24, further comprising: a local storage to store some of the media itemsto be used to build the media project.
 26. The system of claim 25,further comprising: a web folder configured as a folder on the webbrowser.
 27. The system of claim 26, further comprising: an uploadcontrol tool to enable uploading of the media items stored in said localstorage to the media publishing system by dragging and dropping themedia items directly into the web folder.
 28. The system of claim 23,further comprising: a code publishing service to download a project codeto execute the media project from the client system.
 29. A method ofbuilding, publishing, and accessing a media project, comprising:selecting a category of the media project; selecting a first template ofmedia items from the category, said first template of media itemsincluding a plurality of media slots, each media slot capable ofreceiving media items in a particular arrangement; and selecting andarranging the media items in said each media slot.
 30. The method ofclaim 29, further comprising: selecting publication parameters; andstoring the media project.
 31. The method of claim 30, wherein thepublication parameters include a media project name.
 32. The method ofclaim 30, wherein the publication parameters include a publicationlevel, which indicates a range of users that will have access to themedia project.
 33. The method of claim 32, wherein the publicationparameters include a security level, which restricts access within thepublication level.
 34. The method of claim 30, wherein the publicationparameters include a method of announcement of the stored media project.35. The method of claim 29, further comprising: downloading a projectcode to execute the media project.
 36. The method of claim 35, whereinthe project code includes layout information and features of the mediaproject stored as requests in the project code, such that changes madeto templates for one media project are reflected in other mediaprojects.
 37. The method of claim 29, wherein selecting and arrangingthe media items in said each media slot includes importing media itemstransparently to a user.
 38. The method of claim 29, wherein selectingand arranging the media items in said each media slot includes selectingthe media items from a list, wherein the list includes media itemsdistributed among multiple physical locations.
 39. The method of claim29, wherein selecting a first template of media items includes changingthe first template to a second template of media items within the samecategory while maintaining all the media items in the first template.40. The method of claim 29, wherein said each media slot includes agenre and a target format.
 41. The method of claim 40, wherein the genreindicates a type of media item that can be assigned to said each mediaslot.
 42. The method of claim 41, wherein the genre is image, video,audio, or animation.
 43. The method of claim 40, wherein the targetformat indicates a format in which the template causes the media item tobe requested when the media item for said each media slot is to bepresented.
 44. The method of claim 43, wherein the target format is aJPG, GIF, bitmap, or other related format.
 45. The method of claim 40,wherein selecting and arranging the media items includes selecting aspecific format of each media item, wherein the specific format can bedifferent than the target format specified for the media slot of saideach media item.
 46. The method of claim 29, wherein the categoryincludes albums, journals, scrapbooks, music players, e-cards, andgames.
 47. A method of providing a media publishing service, comprising:connecting the media publishing service to a user; enabling the user tobuild, publish, and access a media project using templates of mediaitems grouped into categories; and providing a file system to allow theuser to upload, store, and/or access the media items.
 48. A computerprogram, stored in a tangible storage medium, for use in publishing amedia project, the program comprising executable instructions that causea computer to: select a category; select a template of media items fromthe category, said template of media items including a plurality ofmedia slots, each media slot capable of receiving media items in aparticular arrangement; and select and arranging the media items in saideach media slot.
 49. The computer program of claim 48, furthercomprising executable instructions that cause a computer to: selectpublication parameters; and store the media project.
 50. A mediapublishing system, comprising: a means for connecting the mediapublishing system to a user; a means for enabling the user to build,publish, and access a media project using templates of media itemsgrouped into categories; and a means for providing a file system to saidmeans for enabling, where the file system allows the user to accessmedia items.
 51. A client system for accessing and utilizing a mediapublishing system, comprising: a means for connecting a user to themedia publishing system; and a means for enabling the user to build,publish, and access a media project using templates of media itemsgrouped into categories.
 52. A media publishing system, comprising: ameans for selecting a category; a means for selecting a template ofmedia items from the category, said template of media items including aplurality of media slots, each media slot capable of receiving mediaitems in a particular arrangement; and a means for selecting andarranging the media items in said each media slot.